Field of the Invention
The present invention relates to the development of control units, such as are used in the automotive industry or in the aviation industry, for example, for controlling technical systems such as, e.g., engines or brakes. In particular, the present invention concerns testers that are used in the development process for control units.
Description of the Background Art
The development of control units has become a highly complex process. New control units and new control functions should thus be tested as early in the development process as possible in order to verify general functionality and to set the direction for further development. Towards the end of the development process, it is important to test the control unit, which has already undergone extensive development, as comprehensively as possible in order to make necessary modifications based on the test results before the control unit comes into use or enters mass production, so that it functions as desired under all conditions in later operation.
Two exemplary steps of the development process in which testers are used for testing the control unit are described below. So-called hardware-in-the-loop simulators (HIL simulators) are employed at a fairly late stage of the development process. Such HIL simulators contain a model of the technical system to be controlled and/or regulated, with the model being present in software. The HIL simulator also contains an electrical input/output interface to which it is possible to connect the control unit, which has already undergone extensive development and is physically present as hardware. The functionality of the control unit can now be tested in various simulation passes, wherein it is possible to observe how the model of the technical system to be controlled reacts to the signals of the control unit, and how the control unit reacts to the events predefined by the model of the technical system to be controlled. In this process, it is possible to simulate not only normal operation, but also faults in the technical system to be controlled as well as faults in the control unit.
Rapid control prototyping (RCP) is a development step that takes place closer to the start of the development process. In RCP, the tester is used on the control unit side. In other words, in rapid control prototyping the tester takes on the role of a prototype of the control unit that is being developed. The tester contains a model of the control unit to be tested. Because of the early stage of development, the model of the control unit to be tested is oftentimes still fairly rudimentary in comparison to the later, final control unit. However, in some cases the model can also be very close in technical terms to the final control unit, or even largely identical thereto with regard to the software. Often, no hardware implementation of the control unit is yet in existence; instead, the model of the control unit to be tested that is present in the tester is a software model. The tester can be connected through an input/output interface to the technical system to be controlled itself, or to the control unit that exists to date for the technical system to be controlled. In the first case, there is a direct connection between the control unit to be tested, in the form of a software model, and the technical system to be controlled, which is physically present. In the second case, the control unit that exists to date is the technical system to be controlled by the RCP tester. This control of the control unit that exists to date results in a modification of the control method of the control unit that exists to date, making it possible to test new control functionality by means of the externally connected RCP tester, an arrangement that is also referred to as bypassing.
In both examples cited (HIL simulator and RCP tester), there is a tester in which a software model is present that represents the behavior of a technical system or the behavior of the control unit, and consequently is referred to hereinafter as a behavioral model. This behavioral model can be connected to an external device through the input/output interface so that tests can be carried out. In the case of RCP, the tester contains a behavioral model of the control unit to be tested, and is connected to the technical system to be controlled, for example an engine/motor vehicle. In the case of HIL, the tester contains a behavioral model of the technical system to be controlled, for example an engine model, and is connected to the control unit to be tested.
As already indicated, the tester has an input/output interface through which the tester is connected to the technical system to be controlled or to the control unit to be tested, depending on the application case. This input/output interface is connected in the tester to the behavioral model present in the tester so that the behavioral model can communicate with the applicable hardware through the input/output interface. The tester has a plurality of input/output functions for this connection of the behavioral model with the input/output interface. These input/output functions constitute the connecting link between the behavioral model on one side and the physically present input/output interface on the other side. One and the same tester can be used for different simulations. In other words, one and the same tester can be used with different behavioral models present in the tester and with different hardware to be tested that is connected to the tester. It is evident that different channels of the input/output interface and different input/output functions are required for different connected devices/systems and for different behavioral models.
Since a plurality of connections are involved and it is necessary to define properties for the input/output signals for each of these connections, it is desirable to be able to verify the creation of the connection after an initial configuration of the signal paths between the hardware and behavioral model through selected and configured input/output interfaces.
The term configuration can be understood to include information about the data type, value range, resolution, and/or the units of a signal value, among other information. In addition, the term configuration is also to be understood to include signal widths, signal limit values, or also scaling adjustments of the signal, e.g. through linear or general mathematical functions or with the aid of lookup tables. In the event of inconsistencies in this regard between the hardware port and the associated model port, an adjustment, for instance typecasting, which is to say a conversion of the data type of a signal, by the input/output function may be necessary. The terms model port and hardware port are understood within the scope of the present invention to mean, e.g., inputs or outputs of configuration devices for a hardware component or a model, wherein the configuration devices can take the form of blocks of a configuration block diagram, for example.
With the complexity of today's embedded systems, the configuration of such a tester can extend to a number of input/output interfaces. In order to keep the hardware that is to be connected from being placed at risk by misconfiguration, for example by a maximum output voltage being exceeded because a data type was chosen incorrectly, measurement hardware is customarily used to measure and verify output values at the hardware pins after executing a simulation of the behavioral model. If an output value is not within the expected parameters, it is necessary to search for an incorrect configuration.
This method of measurement and adjustment of the configuration can thus only take place with the tester present, and moreover may require a number of simulation runs, which can involve a great expenditure of time.